Question: Is each requirement consistent with the overall objectives for the system/product?

Example: Suppose we're developing a mobile banking app. One of the objectives is to provide users with secure access to their accounts. If a requirement states that users should be able to log in without entering a password, it would not be consistent with the security objective.

Question: Have all requirements been specified at the proper level of abstraction?

Example: In our mobile banking app, a requirement might state, "Users can transfer money between accounts." This requirement is at an appropriate level of detail for the early stages of the project. However, specifying the encryption algorithm used for secure transactions might be too technical at this stage.

Question: Is the requirement really necessary?

Example: If stakeholders request a feature for sending virtual gifts to friends within the banking app, it's essential to evaluate whether this aligns with the primary objective of financial transactions. If it's not essential, it may add unnecessary complexity to the system.

Question: Is each requirement bounded and unambiguous?

Example: A requirement stating, "The app should load quickly," is ambiguous because "quickly" is subjective. Instead, a bounded requirement could be, "The app should load within 3 seconds."

Question: Does each requirement have attribution?

Example: Each requirement should specify who requested it or who it's important for. For instance, if a requirement comes from regulatory compliance, it should be attributed to the relevant regulatory authority.

Question: Do any requirements conflict with each other?

Example: If one requirement states that transactions should be processed instantly, and another requires thorough fraud detection, there might be a conflict. Resolving conflicts ensures that all requirements can be met simultaneously.

Question: Is each requirement achievable in the technical environment?

Example: If a requirement demands real-time transaction processing but the technical infrastructure doesn't support it, it's not achievable. Ensuring feasibility avoids setting unrealistic expectations.

Question: Is each requirement testable?

Example: A requirement like "Users should have a seamless experience" is vague and challenging to test. Instead, requirements should be specific enough to create test cases, such as "The login process should not take more than 10 seconds."

Question: Does the requirements model reflect the information, function, and behavior of the system?

Example: If the app is supposed to allow users to view transaction history, the requirements should cover aspects like how transactions are stored, retrieved, and displayed.

Question: Has the requirements model been partitioned effectively?

Example: Breaking down requirements into smaller, manageable chunks helps understand the system's complexity. Additionally, using established patterns for common functionalities can simplify the requirements and ensure consistency across different parts of the system.